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(57) Abstract: The invention concerns a method for managing micropayment transactions, between a trader (104) and at least a 
client (101, 201), which consists in using for each new transaction means for allocating a new transaction number (TO) which follows 
according to a pre-established numbering sequence a last stored number (LTO) and means for updating the register of last stored 
number (LTO), the updating means recording the new transaction number (TO), each transaction number (TO) capable of being 
verified by a financial intermediary (100): 
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(57) Abrege : Pour gerer des transactions de micropaiement, entre un marchand (104) et au moins un client (101, 201), on met 
en oeuvre pour chaque nouvelle transaction un moyen d' allocation de nouveau numero de transaction (TO) qui suit selon un ordre 
preetabli de numerotation un dernier numero memorise (LTO) et un moyen de mise a jour du registre de dernier numero memorise 
(LTO), le moyen de mise a jour enregistrant le nouveau numero de transaction (TO), chaque numero de transaction (TO) etant sus- 
ceptible d'etre verifie par un intermediaire financier (100). 
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Systeme et procede de gestion de transaction de micropaiement 
dispositifs client marchand et intermediaire financier. 

Domaine de ['invention 
5 La presente invention se rapporte au domaine de la gestion des 

transactions de micropaiements. 

Plus precisement, Tinvention concerne plus particulierement un 

systeme, un procede et des dispositifs de gestion de transaction de 

micropaiement mettant en oeuvre au moins un client susceptible d'effectuer 

10 une transaction de micropaiement avec un marchand de biens et/ou de 

services, cette transaction etant validee par un intermediaire financier (en 

anglais « broker ») et s'effectuant sous forme de jetons representant une unite 

de paiement. 

Selon un deuxieme aspect, I'invention concerne un terminal numerique 
15 multimedia possedant au moins un processeur securise et adapte en tant que 
client a effectuer des transactions de micropaiement. Le terminal pouvant etre 
notamment un decodeur numerique multimedia (en anglais « set top box »). 
Le processeur securise est amovible (par exemple lorsqu'il s'agit d'une carte a 
puce) ou fixe. 

20 Par micropaiement, on entend ici un paiement d'un montant reduit, par 

exemple de quelques centimes a quelques dizaines ou centaines de francs 
(ou d'un montant reduit dans toute autre monnaie d'echange). 

Etat de la technique 

L'emergence des systemes de transactions de micropaiement mis en 
25 ceuvre par le biais de reseaux de communication, tels que par exemple le 
reseau mondial Internet, a souleve le probleme de la securite des transactions 
entre clients et marchands, ainsi que de la securite des informations 
echangees au cours de ces transactions. Par ailleurs, la faiblesse des 
montants de transactions de micropaiement necessite des solutions 
30 relativement legeres a mettre en oeuvre. 

Notamment Tun des problemes principaux de la securite des 
transactions est la possibility pour un marchand de copier un jeton et de 
Putiliser frauduleusement. De nombreux systemes de gestion des transactions 
de micropaiement ont ete proposes pour qu'il n'y ait pas duplication des 
35 retraits d'argent correspondant a une seule transaction. Ces systemes sont 
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par exemple decrits dans le livre, "Electronic payment system" ecrit par Donal 
O'Mahony, Michael Peirce et Hitesh Tewari, publie chez Artech House en 
1997. Le chapitre 6 de cet ouvrage, « electronic cash payment system » decrit 
plusieurs methodes anti-duplication, dans des systemes de paiement cash, 
5 notamment les systemes Ecash, CAFE et Netcash. 

Dans le systeme Ecash de la societe Digicash, le client genere un 
numero de serie aleatoire qu'il affecte a chaque piece de monnaie 
electronique susceptible d'etre utilisee tel que la probability d'avoir deux fois le 
meme numero est tres faible. Ces pieces sont delivrees par une banque ou un 
10 intermediate financier. Pour eviter la duplication des pieces electroniques par 
un client, la banque doit enregistrer le numero de serie de chaque piece qui 
est y deposee. Cela necessite I'utilisation de bases de donnees enormes. 

Sur des systemes tres securises tel que le projet CAFE (En anglais 
« Conditional Access For Europe ») utilisant entre autres la cryptographie et 
15 par exemple des cartes a puces, les intermediates financiers conservent une 
base de donnees relatives aux derniers paiements effectues. Meme si les 
bases de donnees du projet CAFE sont plus reduites que dans le systeme 
Ecash, leurgestion reste lourde. 

Dans le systeme Netcash, un serveur d'argent conserve en memoire 
20 les numeros de serie des pieces de monnaie electroniques qu'il a lui-meme 
mises en circulation et auxquelles il a attribue un numero de serie. Cela 
necessite aussi une base de donnee de grande taille. 

Dans ce meme ouvrage, le chapitre 7, "Micropayment systems", decrit 
des methodes anti-duplication plus adaptees aux systemes de micropaiement, 
25 notamment les systemes Millicent, SubScrip, PayWord et MicroMint 

Dans le schema Millicent developpe par la societe Digital Equipment 
Corporation, le marchand verifie qu'une unite de monnaie ayant un 
identificateur donne qui correspond a un numero de serie n'a pas deja ete 
depensee. Aussi, le marchand doit maintenir une base de donnees contenant 
30 les identificateurs des unites de monnaie emises. 

Dans le systeme SubScrip developpe par I'universite de Newcastle en 
Australie, le marchand possede une base de donnees contenant tous les 
identificateurs de monnaie valides. 

Dans ie systeme PayWord developpe par le MIT aux Etats Unis et 
35 1'institut des sciences Weizman en Israel, le micropaiement est base sur 
Tutilisation de credit qui permet la delivrance de certificats Payword. Ces 
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certificats sont ensuite utilises par un utilisateur pour construire des chaTnes 
Payword qui serviront aux paiements et permettront au marchand de verifier 
la validite de ceux-ci. La complexite reside ici dans la gestion des certificats. 

Dans le systeme MicroMint developpe par le MIT aux Etats Unis et 
5 I'institut des sciences Weizman en Israel, c'est I'intermediaire financier qui 
verifie si deux transactions n ! ont pas ete dupliquees. Neanmoins, celle-ci est 
basee sur la non conservation de I'anonymat du client. En cas de fraude, 
I'intermediaire financier ne pourra cependant pas distinguer si c'est un client 
ou un marchand qui en est responsable. 

10 II existe de nombreux systemes et procedes de gestion de transaction 

de micropaiement, presentant des niveaux de securite et de complexite divers 
et dans lesquels un client dispose d'un porte-monnaie electronique. Mais, on 
ne connaTt a ce jour aucun systeme ou protocole de mise en oeuvre simple, 
presentant une securite satisfaisante pour les differents acteurs des 

15 transactions (intermediaire financier, client, marchand). 

D'une maniere generate, un inconvenient des mecanismes anti- 
duplication de Tart anterieur est la lourdeur de leur mise en oeuvre (des bases 
de donnees de taille importantes memorisant des numeros de transactions ou 
de jetons sont notamment necessaires) ou la non preservation de I'anonymat 

20 des clients. 

Par ailleurs, un inconvenient des systemes a micropaiement est qu'ils 
necessitent un terminal dedie a I'interfagage avec un processeur securise 
propre au client. 

L'invention selon ses differents aspects a notamment pour objectif de 
25 pallier ces inconvenients de Tart anterieur. 

Plus precisement, un objectif de ('invention est de fournir un systeme et 
un procede de gestion des transactions de micropaiement qui soient simples, 
faciles d'utilisation et peu couteux a mettre en oeuvre. 
Expose de Tinvention 

30 Dans ce but, l'invention propose un procede de gestion de transaction 

de micropaiement, entre un marchand et au moins un client remarquable en 
ce qu'a chaque nouvelle transaction, 

- Ie marchand alloue un nouveau numero de transaction qui suit selon 
un ordre preetabli de numerotation un dernier numero memorise et 
35 - le marchand met a jour un registre de dernier numero memorise en 

enregistrant le nouveau numero de transaction, 
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chaque numero de transaction etant susceptible d'etre verifie par un 

intermediate financier. 

Ainsi, I'invention permet avantageusement d'allouer d'une maniere 

simple des numeros de transactions qui pourront etre facilement verifiees 
5 pour eviter les duplications. Ainsi, tout en ayant une bonne securite dans les 

transactions, ni le marchand, ni I'intermediaire financier n'ont besoin de gerer 

de bases de donnees de grande taille. De plus, I'anonymat du client est 

conserve vis-a-vis du marchand. 

Selon une caracteristique particuliere, le procede de gestion de 
10 transaction de micropaiement est remarquable en ce qu'au moins un client 

parmi lesdits clients est un terminal multimedia numerique et/ou analogique. 
Ainsi, de fagon avantageuse, I'invention se prete bien a tout type de 

transactions de micropaiement et notamment aux transactions impliquant un 

client de type terminal multimedia numerique et/ou analogique, par exemple 
15 un decodeur multimedia numerique. 

Selon une caracteristique particuliere, le procede de gestion de 

transaction de micropaiement est remarquable en ce que le terminal 

multimedia comprend au moins un processeur securise fixe ou amovible 

necessaire a la mise en oeuvre desdites transactions de micropaiement. 
20 Ainsi, I'invention se prete avantageusement au cas ou le terminal est 

equipe d'un lecteur de processeur securise ce qui est generaiement le cas 

des decodeurs multimedia numeriques et/ou s'il contient lui-meme un 

processeur securise. On a ainsi en outre une grande souplesse d'utilisation de 

ce terminal pour effectuer des transactions de micropaiements. 
25 Selon une caracterique particuliere, le procede de gestion de 

transaction de micropaiement est remarquable en ce que le marchand est 

equipe d'un lecteur de processeur securise amovible. 

Selon une caracterique particuliere, le procede de gestion de 

transaction de micropaiement est remarquable en ce qu'au moins un client est 
30 un processeur securise amovible lisible par le lecteur de processeur securise 

amovible du marchand. 

Ainsi, dans ce mode de realisation avantageux de I'invention, le client 

peut effectuer la transaction directement chez le marchand tout en ayant une 

grande securite dans les transactions. 
35 Selon une caracteristique particuliere, le procede de gestion de 

transaction de micropaiement entre un client et un marchand par un 
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intermediate financier est remarquable en ce que pour un premier ensemble 
d'au moins une transaction realisee par le marchand et possedant un numero 
de transaction alloue par le marchand, I'intermediaire financier effectue pour 
chaque transaction du premier ensemble 
5 - au cours d'une premiere etape, une operation de verification de 

ladite transaction consistant a determiner si ledit numero de 
transaction suit selon un ordre preetabli un dernier numero de 
transaction enregistre puis 

- au cours d'une deuxieme etape, 

10 - lorsque le resultat de ladite operation de verification est negatif, 

une operation de rejet de ladite transaction 
- et lorsque le resultat de ladite operation de verification est positif, 
une operation d'enregistrement dudit numero de transaction en 
tant que dernier numero de transaction pour ledit marchand. 
15 Ainsi, Tintermediaire financier peut avantageusement verifier la validite 

d'une transaction pour la rejeter si elle n'est pas valide et eviter la duplication 
des transactions. 

Selon une caracteristique particuliere de invention, le procede de 
gestion de transaction de micropaiement est remarquable en ce que 
20 I'operation de verification de la transaction comprend en outre une operation 
de verification de signature de la transaction. 

Ainsi, on peut avantageusement, effectuer des verifications 
complementaires pour detecter une eventuelle fraude. 

Selon une caracteristique particuliere, le procede de gestion de 
25 transaction de micropaiement est remarquable en ce que I'operation de 
verification de la transaction est effectuee selon un indice de fiabilite du 
marchand. 

Ainsi, I'invention permet avantageusement de limiter le nombre de 
verifications quand un marchand est fiable et de se polariser sur les 
30 marchands les moins fiables. 

Selon une caracteristique particuliere, le procede de gestion de 
transaction de micropaiement est remarquable en ce que la verification de 
signature de la transaction est effectuee : 

- systematiquement si I'indice de fiabilite du marchand est inferieur a 
35 un seuil ; 
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- selon un mecanisme non systematique si Pindice de fiabilite du 
marchand est superieur au dit seuil. 

Ainsi, I' intermediate financier peut avantageusement effectuer de 
maniere pragmatique les verifications les plus complexes en fonction de la 
5 fiabilite du marchand. 

Selon une caracteristique particuliere, le procede de gestion de 
transaction de micropaiement est remarquable en ce que lorsque le resultat 
de ['operation de verification de signature de la transaction est negatif, le 
procede comprend en outre une operation de verification des signatures d'un 
10 deuxieme ensemble de transactions. 

Selon une caracteristique particuliere, le procede de gestion de 
transaction de micropaiement est remarquable en ce que le deuxieme 
ensemble de transactions comprend toutes les transactions presentees par le 
marchand a Pintermediaire financier depuis une transaction de reference et 
15 dont la signature n'a pas deja ete verifiee 

Selon une caracteristique particuliere, le procede de gestion de 
transaction de micropaiement est remarquable en ce que la transaction de 
reference est : 

- la derniere transaction ayant re$u une acceptation de paiement ; 
20 et/ou 

- la derniere transaction precedent la transaction de micropaiement 
dont la signature a ete verifiee. 

Ainsi, de fagon avantageuse, I'intermediaire financier peut effectuer des 
verifications complementaires et appropriees quand la fiabilite du marchand 
25 est remise en cause. 

Selon une caracteristique particuliere, le procede de gestion de 
transaction de micropaiement est remarquable en ce que Pintermediaire 
financier est susceptible de mettre a jour la fiabilite du marchand en fonction 
du resultat d'au moins une des verifications de signature. 
30 Ainsi, preferentiellement, Pindice de fiabilite evolue et la verification des 

transactions est adaptative. 

Selon une caracteristique particuliere, le procede de gestion de 
transaction de micropaiement est remarquable en ce que I'ordre preetabli a 
ete etabli par le marchand ou Pintermediaire financier ou un operateur 
35 technique. 
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Ainsi, de fagon avantageuse, I'ordre preetabli peut etre defini par Pun 
des intervenants majeurs dans les transactions ou dans la mise en oeuvre de 
moyens permettant des transactions. On peut de cette maniere optimiser 
Pordre etabli selon un critere propre a Tun des intervenants. 
5 Selon une caracteristique particuliere, Ie procede de gestion de 

transaction de micropaiement est remarquable en ce que ledit ordre preetabli 
est I'ordre naturel des entiers croissants et/ou un ordre chronologique de type 
heure et/ou date. 

Ainsi, on peut avantageusement avoir un ordre preetabli permettant 
10 une mise en oeuvre simple du procede de gestion de transaction. 

Selon une caracteristique particuliere, le procede de gestion de 
transaction de micropaiement est remarquable en ce que I'ordre preetabli est 
un ordre en boucle. 

Ainsi, d'une fagon avantageuse, on simplifie la taille des numeros de 
15 transactions tout en evitant tout risque de depassement d'une valeur 
maximale. 

(-'invention propose en outre un systeme remarquable en ce qu'il 
comprend des moyens adaptes a la mise en oeuvre du procede de gestion de 
transaction de micropaiement decrit precedemment. 
20 L'invention propose en outre un dispositif de gestion de transaction de 

micropaiement, entre le dispositif et au moins un client remarquable en ce 
qu'il comprend pour chaque nouvelle transaction, 

- un moyen d'allocation de nouveau numero de transaction qui suit 
selon un ordre preetabli de numerotation un dernier numero 

25 memorise ; et 

- un moyen de mise a jour du registre de dernier numero memorise le 
moyen de mise a jour enregistrant le nouveau numero de 
transaction ; 

chaque numero de transaction etant susceptible d'etre verifie par un 

30 intermediate financier. 

L'invention propose en outre un dispositif de gestion de transaction de 
micropaiement entre un client et un marchand remarquable en ce que pour un 
premier ensemble de transactions realisees par le marchand et possedant un 
numero de transaction alloue par le marchand, le dispositif comprend pour 

35 chaque transaction du premier ensemble : 
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- un moyen de verification de la transaction adapte a determiner si le 
numero de transaction suit selon un ordre preetabli un dernier 
numero de transaction enregistre ; 

- lorsque le resultat de I'operation de verification est negatif, un 
5 moyen de rejet de la transaction ; 

- et lorsque le resultat de ('operation de verification est positif, un 
moyen d'enregistrement du numero de transaction en tant que 
dernier numero de transaction pour le marchand. 

Les caracteristiques particulieres et les avantages des dispositifs et du 
10 systeme de gestion de transaction de micropaiement etant les memes que 
ceux du procede de gestion de transaction de micropaiement, ils ne sont pas 
rappeles ici. 

L'invention propose en outre un terminal numerique multimedia 
remarquable en ce qu'il comprend au moins un processeur securise fixe ou 
15 amovible et que ledit processeur securise est adapte a effectuer des 
transactions de micropaiements en tant que client. 

Selon une caracteristique particuliere, le terminal numerique multimedia 
est remarquable en ce qu'il est un decodeur numerique multimedia. 

Ainsi, de fagon avantageuse, un terminal multimedia notamment quand 
20 il s'agit d'un decodeur numerique multimedia peut etre facilement utilise pour 
effectuer des transactions de micropaiement En outre bien souvent, un tel 
terminal possede un lecteur de cartes a puces dediees a des transactions 
vers un marchand donne. ^adaptation d'un tel terminal pour des transactions 
de micropaiement selon l'invention est relativement simple et peu couteuse a 
25 mettre en ceuvre. 

Breve description des dessins 

D'autres caracteristiques et avantages de l'invention apparaftront plus 
clairement a la lecture de la description suivante de modes de realisation 
preferentiels, donnes a titre de simple exemple illustratif et non limitatif, et des 
30 dessins annexes, parmi lesquels : 

la figure 1 presente un synoptique general d'une transaction de 
micropaiement entre un client, un marchand et un intermediaire financier, 
conforme a l'invention selon un mode particulier de realisation ; 
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la figure 2 presente un synoptique general cTune transaction de 
micropaiement selon une premiere variante, conforme a Tinvention selon un 
mode particulier de realisation ; 

la figure 3 presente un decodeur numerique multimedia avec lecteur de 
5 processeur securise amovible (client), conforme a invention selon un mode 
particulier de realisation ; 

la figure 4 presente un decodeur numerique multimedia avec 
processeur securise integre (client), conforme a invention selon un mode 
particulier de realisation ; 
10 la figure 5 presente un processeur securise (client), conforme a 

Tinvention selon un mode particulier de realisation ; 

la figure 6 presente un schema d'un dispositif de type marchand, 
conforme a Tinvention selon un mode particulier de realisation ; 

la figure 7 presente un schema d'un dispositif de type marchand avec 
15 lecteur integre de processeur amovible selon la premiere variante, conforme a 
Tinvention selon un mode particulier de realisation ; 

la figure 8 presente un schema d'un dispositif de type intermediate 
financier, conforme a Tinvention selon un mode particulier de realisation ; 

la figure 9 presente un protocole de chargement des jetons sur un 
20 processeur securise, conforme a Tinvention selon un mode particulier de 
realisation ; 

la figure 10 presente un protocole de depense des jetons sur un 
processeur securise, conforme a Tinvention selon un mode particulier de 
realisation ; 

25 la figure 11 presente un protocole de rachat des jetons au marchand, 

conforme a Tinvention selon un mode particulier de realisation ; 

la figure 12 presente un organigramme de generation des numeros de 
transactions par le marchand, conforme a Tinvention selon un mode particulier 
de realisation ; 

30 la figure 13 presente un organigramme de validation de transactions 

par Tintermediaire financier, conforme a Tinvention selon un mode particulier 
de realisation ; 

la figure 14 presente un organigramme de validation de transactions 
par Tintermediaire financier selon une deuxieme variante, conforme a 
35 Tinvention selon un mode particulier de realisation. 
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Description detaillee de modes de realisation de invention 

Le principe general de Pinvention selon son premier aspect repose sur 

Pattribution de numeros de transaction par un marchand selon un ordre 

preetabli. Le marchand n'a besoin de memoriser qu'un dernier numero 

5 attribue. Un intermediaire financier verifie qiTune transaction n'a pas ete 

dupliquee en testant les numeros de transactions : deux transactions 

provenant du meme marchand ne peuvent avoir le meme numero. II suffit 

alors que Pintermediaire financier garde en memoire le dernier numero de 

transaction en provenance d'un marchand et le compare au numero d'une 

10 nouvelle transaction en provenance du meme marchand pour valider cette 
nouvelle transaction. L'intermediaire financier peut par ailleurs effectuer des 
verifications complementaires telles que des verifications de signature. Ces 
verifications etant plus lourdes a mettre en ceuvre, Pintermediaire financier 
peut adapter leur frequence a un indice de fiabilite de chaque marchand qu'il 

15 met a jour lui-meme. 

Selon un deuxieme aspect, ['invention met en oeuvre un client de type 
terminal numerique multimedia pouvant etre notamment un decodeur 
numerique multimedia, ce client etant susceptible d'effectuer des transactions 
de micropaiement. Ce client comprend notamment au moins un processeur 

20 securise. Generalement, les decodeurs numeriques possedent un lecteur de 
carte a puces pour des transactions vers un fournisseur de contenu 
numerique tel que, par exemple, un programme de television. Conformement 
a Pinvention, ce lecteur est utilise pour des transactions de micropaiement 
moyennant des adaptations peu couteuses. 

25 On note que dans le mode prefere de realisation, un processeur 

securise fixe ou amovible adapte a effectuer des transactions de 
micropaiement en tant que client met en oeuvre une paire de cles 
asymetriques qu'il possede en propre (cryptographie asymetrique) et qu'il 
utilise pour les transactions de micropaiement. 

30 On presente, en relation avec la figure 1 un synoptique general de 

transaction de micropaiement mettant en oeuvre un client 101, un marchand 
104 et un intermediaire financier 100. Par souci de clarte, on assimile les 
terminaux ou dispositifs et leur fonction ; ainsi, le client 101, le marchand 104 
et Pintermediaire financier 100 sont des terminaux ou dispositifs. 
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Pour participer a une transaction de micropaiement, le client 101 est un 
terminal numerique multimedia qui comprend deux entites : 

- un processeur securise fixe ou amovible 102 , utilise comme moyen 
de stockage de donnees securisees et comme moyen 

5 d'authentification du client 101. On peut envisager que ce 

processeur securise ait d'autres fonctionnalites, telles que par 
exemple la gestion de Faeces conditionnel a des programmes de 
television ; 

- un decodeur numerique multimedia pouvant communiquer avec le 
10 marchand 104 et I'intermediaire financier 100 via un reseau. 

Le decodeur numerique multimedia 103 est generalement muni d'un 
lecteur de type carte a puce pour des transactions de type paiement 
d'emissions de television a la carte (en anglais « pay-per-view »). Dans ce 
cas, la carte a puce est dediee aux transactions avec un marchand unique, de 
15 type operateur de television. Neanmoins, conformement a Pinvention, ce 
lecteur utilise un processeur securise amovible 102 pour effectuer des 
transactions de micropaiement avec un marchand de services ou de biens 
quelconques. 

Selon une variante de mise en ceuvre, le decodeur numerique 
20 multimedia 103 integre un processeur securise 102 fixe. 

On notera que le bloc reference 100 de la figure 1 represente, par souci 
de simplification, I'intermediaire financier ou la banque du client 101 et/ou du 
marchand 104. On peut bien sur envisager que le client 101 et le marchand 
104 soient clients du meme intermediate financier ou d'intermediaires 
25 financiers differents. Par la suite, on suppose que le client 101 et le marchand 
1 04 ont le meme intermediaire financier. 

Le client possede un porte-monnaie electronique pour effectuer ses 
transactions de micropaiement. Ce porte-monnaie est gere par le processeur 
securise 102. 

30 Avant tout achat, si son porte-monnaie est vide ou insuffisamment 

approvisionne, le client 101 doit se procurer des jetons aupres d'un 
intermediaire financier 100. Dans ce dessein, le client 101 effectue une 
requete de macropaiement 105 a I'intermediaire financier 100. Cette requete 
constitue une autorisation a debiter un compte bancaire qui est propre au 

35 client 101 d'un montant egal a la valeur des jetons qu'il souhaite acquerir. 
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Si la requete est valide, Tintermediaire financier 100, transmet les 
jetons 106 au client 101 dont le porte-monnaie sera credite de la somme 
requise. 

Apres avoir effectue une requete d'achat aupres du marchand 104, le 
5 client 101 effectue une transaction de micropaiement 109 puis si la 
transaction est valide le marchand delivre la marchandise 110 au client 101. 

Pour crediter son propre compte bancaire, le marchand 104 presente a 
I'intermediaire financier 100, les jetons 107 correspondants aux transactions 
effectuees par ses clients. L'intermediaire financier 100 verifie la validite des 
10 transactions et effectue un rachat 108 des jetons presentes. 

Selon une variante de realisation de invention decrite a la figure 2, le 
marchand 204 comprend un lecteur de processeur securise et le client 
comprend un processeur securise amovible 202. Pour les transactions de 
macro et micropaiements, le processeur securise amovible 202 est insere 
15 dans le lecteur du marchand 204. 

Les autres elements et echanges effectues sont similaires aux 
elements et echanges de la figure 1 precedemment decrite qui portent les 
memes numeros de reference et ne seront decrits davantage. 

On note cependant que les echanges de donnees pour le 
20 macropaiement 105 et la creation de jetons 106 se font par l'intermediaire du 
marchand 204 qui reste transparent pour ces operations. 

La figure 3 illustre schematiquement un decodeur numerique 
multimedia 103 avec lecteur de processeur securise tel qu'illustre en regard 
de la figure 1. 

25 Le decodeur comprend relies entre eux par un bus d'adresses et de 

donnees 303 : 

- un processeur 302 ; 

- un modem 301 ; 

- un lecteur de processeur securise 306 
30 - une memoire vive 305 ; et 

- une memoire non volatile 304. 

Chacun des elements illustres en figure 3 est bien connu de Thomme 
du metier. Ces elements communs ne sont pas decrits ici. 

On observe cependant que le modem 301 est adapte a emettre et 
35 recevoir des signaux representatifs de donnees multimedia en provenance 
d'un emetteur/recepteur exterieur non represents tel que notamment un 
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diffuseur de programmes de television, un lecteur de DVD, de CD audio ou 
CD-ROM. Le modem 301 est notamment adapte a mettre en forme les 
signaux en provenance de Pexterieur sous forme de sequences binaires 
exploitables par le processeur 302 et vice-versa. En outre, le modem 301 est 
5 adapte a emettre des donnees par exemple de type macro ou micropaiement 
vers un reseau auquel sont aussi connectes I'intermediaire financier 100 et le 
marchand 104 ou a recevoir des donnees de ce reseau. 

On observe en outre que le mot « registre » utilise dans toute la 
description designe dans chacune des memoires mentionnees, aussi bien une 

10 zone de memoire de faible capacite (quelques donnees binaires) qu'une zone 
memoire de grande capacite (permettant de stocker un programme entier ou 
I'integralite d'une sequence de donnees de transactions). 

La memoire vive 305 conserve des donnees, des variables et des 
resultats intermediates de traitement. 

15 La memoire non volatile 304 conserve dans des registres qui par 

commodite possedent les memes noms que les donnees qu'ils 
conservent notamment le programme de fonctionnement du processeur 302 
dans un registre « Prog » 306. 

La figure 4 illustre schematiquement un decodeur numerique 

20 multimedia 103 avec processeur securise fixe tel que mentionne en variante 
de la figure 1. 

Hormis le processeur securise fixe qui remplace un lecteur de 
processeur securise amovible, les elements illustres en figure 4 sont similaires 
aux elements de la figure 3 precedemment decrite qui portent les memes 
25 numeros de reference et ne seront decrits davantage. 

On note que le decodeur 103 comprend relies entre eux par un bus 
d'adresses et de donnees 303 : 

- un processeur 302 ; 

- un modem 301 ; 

30 - un processeur securise fixe 406 ; 

- une memoire vive 305 ; et 

- une memoire non volatile 304. 

Le processeur securise fixe 406 est adapte a gerer des transactions de 
micropaiement effectuees par le client 101 . 
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La figure 5 illustre schematiquement un processeur securise 500 tel 
que le processeur securise 102 (respectivement 202) mentionne en regard de 
la figure 1 (respectivement 2). 

Le processeur securise 500 comprend relies entre eux par un bus 
5 d'adresses et de donnees 503 : 

- un processeur 502 ; 

- un interface d'entrees/sorties 501 ; et 

- une memoire non volatile 504 de type EEPROM. 

Chacun des elements illustres en figure 5 est bien connu de I'homme 
10 du metier. Ces elements communs ne sont pas decrits ici. 

On observe cependant que I'interface 501 est adaptee a emettre et 
recevoir des signaux representatifs de donnees de transactions de macro ou 
micropaiement multimedia en provenance d'un emetteur/recepteur exterieur 
tel que notamment un intermediaire financier ou un marchand. 
15 La memoire non volatile 504 conserve dans des registres qui par 

commodite possedent les memes noms que les donnees qu'ils conservent : 
le programme de fonctionnement du processeur 502 dans un registre 
« Prog » 505 , 

- un compteur de jetons dans un registre Tok 506 ; 

20 - une cle publique de signature d'intermediaire financier dans un registre 
BPubK 507 ; 

- une cle publique dans un registre PubK 508 ; 

- une cle privee dans un registre PriK 509 ; et 

- dans un registre Var 510: des nombres ou variables utilises provisoirement 
25 pour certaines operations, tels que des nombres C, A/, n decrits par la 

suite, ou des messages echanges. 

La memoire non volatile 504 est preferentiellement de type EEPROM 
afin que Ton puisse mettre a jour et conserver des parametres tels que le 
contenu du porte-monnaie. 
30 On note que les registres contenant le programme 505, le compteur de 

jetons 506 et les cles 507, 508 et 509 sont par exemple initialises lors de la 
fabrication du processeur securise et/ou lors de I'ouverture d'un compte chez 
un intermediaire financier. 

La figure 6 illustre schematiquement un marchand 104 tel que decrit en 
35 regard de la figure 1. Cette figure a ete representee uniquement dans la 
phase de calcul. 
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Le marchand 104 comprend relies entre eux par un bus d'adresses et 
de donnees 603 : 

- un processeur 602 adapte a la mise en oeuvre de I'organigramme 
decrit dans la figure 12; 

5 - un modem 601 ; 

- une memoire non volatile 604; 

- une memoire vive 605 ; et 

- une memoire non volatile 613 de type EEPROM. 

Chacun des elements illustres en figure 6 est bien connu de I'homme 
10 du metier. Ces elements communs ne sont pas decrits ici. 

On observe cependant que I'interface 601 est adaptee a emettre et 
recevoir des signaux representatifs de donnees de transactions de 
micropaiement en provenance d'un emetteur/recepteur exterieur tel que 
notamment un intermediate financier ou un client 
15 La memoire non volatile 604 conserve dans des registres qui par 

commodite possedent les memes noms que les donnees qu'ils conservent : 
le programme de fonctionnement du processeur 602 dans un registre 
« Prog » 607 ; et 

- un registre « IDM » contenant Tidentificateur du marchand 606 unique pour 
20 I'intermediaire financier. 

La memoire vive 605 conserve des donnees, des variables et des 
resultats intermediates de traitement, dans des registres de memoire portant 
dans la description, les memes noms que les donnees dont ils conservent les 
valeurs. La memoire vive 605 comprend notamment : 
25 - dans un registre Var 612: des nombres ou variables utilises provisoirement 
pour certaines operations, tels que des nombres n decrits par la suite, ou 
des messages echanges. 

La memoire non volatile 613 de type EEPROM conserve dans des 
registres qui par commodite possedent les memes noms que les donnees 
30 qu'ils conservent : 

- un registre « TO » 608 dans lequel est conserve le numero de la 
transaction en cours ; 

- un registre « LTO » 611 dans lequel est conserve le dernier numero de 
transaction alloue ; 

35 - un registre « MpubK» 609 dans lequel est conservee la cle publique du 
marchand ; et 
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- un registre «MpriK» 610 dans lequel est conservee la cle privee du 
marchand. 

La figure 7 illustre schematiquement un marchand 204 tel que decrit en 
regard de la figure 2. Cette figure a ete representee uniquement dans la 
5 phase de calcul. 

Le marchand 204 comprend relies entre eux par un bus d'adresses et 
de donnees 603 : 

- un processeur 602 adapte a la mise en oeuvre de I'organigramme 
decrit dans la figure 12; 

10 - un modem 601 ; 

- une memoire non volatile 604 ; 

- une memoire vive 605 ; 

- une memoire non volatile 613 de type EEPROM ; et 

- un lecteur de processeur securise amovible 71 1 . 

15 Hormis la presence d'un lecteur de processeur securise amovible, les 

elements illustres en figure 7 sont similaires aux elements de la figure 6 
precedemment decrite qui portent les memes numeros de reference et ne 
seront decrits davantage. 

On note que le lecteur de processeur securise 71 1 est adapte a lire un 

20 processeur securise amovible 202 decrit en regard de la figure 2 avec une 
realisation 500 telle que decrite en regard de la figure 5. 

On note que les flux de donnees de transactions vis-a-vis d'un client 
(respectivement d'un intermediaire financier) se font alors par I'intermediaire 
du lecteur de processeur securise amovible 711 (respectivement du modem 

25 601). 

En considerant les figures 1, 2, 6 et 7, il est clair qu'un marchand peut 
effectuer des transactions avec un client distant et/ou avec un client de type 
processeur securise amovible local. 

La figure 8 illustre schematiquement un intermediaire financier 100 tel 
30 que decrit en regard des figures 1 ou 2. Cette figure a ete representee 
uniquement dans la phase de calcul. 

L'intermediaire financier 100 comprend relies entre eux par un bus 
d'adresses et de donnees 803 : 

- un processeur 802 adapte a la mise en oeuvre des organigrammes 
35 decrits dans les figures 13 ou 14; 

- un modem 801 ; 
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- une memoire non volatile 804 ; 

- une memoire vive 805 ; et 

- une memoire non volatile 810 de type EEPROM. 

Chacun des elements illustres en figure 8 est bien connu de I'homme 
5 du metier. Ces elements communs ne sont pas decrits ici. 

On observe cependant que le modem 801 est adapte a emettre et 
recevoir des signaux representatifs de donnees de transactions de macro ou 
micropaiement en provenance d'un emetteur/recepteur exterieur tel que 
notamment un marchand ou un client. 
10 La memoire non volatile 804 conserve dans des registres qui par 

commodite possedent les memes noms que les donnees qu'ils conservent : 

- le programme de fonctionnement du processeur 602 dans un registre 
« Prog » 806 , et 

- un registre « BpriK » 808 dans lequel est conservee la cle privee de 
15 I'intermediaire financier qui sert a generer les certificats pour les autres 

cles publiques du systeme. 

La memoire non volatile 810 de type EEPROM conserve dans des 
registres qui par commodite possedent les memes noms que les donnees 
qu'ils conservent, notamment : 
20 - un registre « MLTO » 807 dans lequel est conserve le numero de la 
derniere transaction valide de chaque marchand connu de Tintermediaire 
financier. 

La memoire vive 805 conserve des donnees, des variables et des 
resultats intermediates de traitement, dans des registres de memoire portant 
25 dans la description, les memes noms que les donnees dont ils conservent les 
valeurs. La memoire vive 805 comprend notamment : 

- dans un registre Var 809: des nombres ou variables utilises provisoirement 
pour certaines operations, tels que des nombres LTV, n decrits par la 
suite, ou des messages echanges. 

30 La figure 9 detaille un protocole de chargement de jetons sur un 

processeur securise destines a des transactions de micropaiement ainsi que 
les flux de donnees correspondants. 

Le chargement de jetons fait intervenir : 

- un processeur securise 900 tel que le processeur 102 decrit en 
35 regard de la figure 1 avec une realisation 500 telle que decrite en 

regard de la figure 5 ; 
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- un decodeur multimedia 901 tel que le decodeur 103 decrit en 
regard de la figure 1 ; et 

- un intermediate financier 902 tel que I'intermediaire financier 100 
decrit en regard de la figure 1. 

5 La procedure de chargement de jetons se fait en deux etapes : 

une etape de macropaiement ou un client achete des jetons 
(monnaie e(ectronique) a nntermediaire financier. Cette etape ne 
concerne pas directement invention. L'homme du metier Pimplante 
par exemple en utilisant le protocole de macropaiement « SET » 
10 (acronyme anglais de « Secure Electronic Transactions ») ; et 

une etape d'authentification et de chargement durant laquelle le 
compteur d'argent du processeur securise est increments du 
montant de la monnaie electronique achetee. 
La procedure de chargement de jetons debute par I'envoi d'un 
15 message de debut de chargement de jetons 903 du decodeur 901 vers le 
processeur securise 900. Puis, le processeur securise 900 genere un nombre 
C aleatoire qu'il transmet au decodeur 901. Ce nombre C est utilise pour 
empecher les attaques de type dictionnaire contre le processeur securise qui 
consisteraient a enregistrer toutes les valeurs possibles d'une fonction de 
20 signature par nntermediaire financier Sign(C,N) qui est utilisee par la suite. Le 
nombre C doit etre suffisamment grand (par exemple un nombre de 64 bits ou 
elements binaires) pour rendre inutiles des attaques de ce type. 

Ensuite, le decodeur contacte I' intermedial re financier 902 pour acheter 
N jetons avec un message 905 contenant les valeurs de N et C. 
25 Une transaction de macropaiement 906 s'effectue alors entre le 

decodeur et I'intermediaire financier. 

Puis, I'intermediaire financier 902 signe le message contenant C et N a 
I'aide de sa cle privee BPriK 808 en utilisant des schemas de signature 
standard PKCS#1 (standard du laboratoire RSA publie dans le document 
30 « PKCS#1 v2.1 :RSA Cryptography standard, RSA Laboratories - Draft 1 - 
September 17, 1999 ») pour obtenir un message signe ou signature 
« Sign(C,N) » 907 qu'il transmet au decodeur 901. Cela permet au decodeur 
et au processeur securise qui vont recevoir ce message d'authentifier que les 
jetons proviennent bien de I'intermediaire financier 902. La fonction de 
35 signature est basee sur un algorithme de cryptage asymetrique. On pourra se 
referer a I'ouvrage « Applied Cryptography » ecrit par de B. Schneier chez 
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Tediteur Wesley&Sons en 1996 pour la mise en oeuvre des methodes de 
cryptage asymetriques. 

Ensuite, le decodeur 901 transmet au processeur securise 900 un 
message 908 contenant la valeur de N ainsi que la signature Sign(C,N). 
5 Le processeur securise 900 verifie a I'etape 909 ('authenticity de ce 

message en verifiant la signature Sign(C,N) a I'aide de la cle publique de 
I'intermediaire financier BPubK contenu dans le registre 507. 

La cle privee de I'intermediaire financier BPriK et sa cle publique 
BPubK de signature seront d'une taille suffisamment elevee pour rendre toute 
10 attaque impossible. Elles pourront par exemple contenir 160 bits ou elements 
binaires. 

Lorsque le message est authentifie, au cours d'une etape 910, le 
compteur de monnaie Tok memorise dans le registre 506 est increments de la 
valeur de N. 

15 On note que dans une realisation telle que decrite en regard de la 

figure 2, le processeur securise 202 et le marchand 204 remplacent pour 
certaines operations le decodeur 901 dans le protocole decrit en regard de la 
figure 9. 

La figure 10presente un protocole de depense de jetons sur un 
20 processeur securise. 

Une depense de jetons fait intervenir : 

- un processeur securise 900 tel que le processeur 102 decrit en 
regard de la figure 1 avec une realisation 500 telle que decrite en 
regard de la figure 5 ; 

25 - un decodeur multimedia 901 tel que le decodeur 103 decrit en 

regard de la figure 1 ; et 

- un marchand 902 tel que le marchand 104 decrit en regard de la 
figure 1. 

Une transaction de micropaiement debute par une requete 1001 
30 d'achat d'une marchandise ou d'un service valant n jetons effectuee par le 
decodeur 901 vers le marchand 902. 

A la reception de cette requete, le marchand genere un numero de 
transaction TO conserve dans le registre 608 suivant un procede decrit en 
regard de la figure 12. Le marchand 902 transmet alors au decodeur 901 un 
35 message 1002 contenant son identificateur IDM conserve dans le registre 606 
et la valeur de TO. 
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Puis, le decodeur 901 communique la valeur de n, le numero de 
transaction TO et I'identificateur du marchand IDM regroupes dans un 
message 1003, au processeur securise 900. 

Apres avoir verifie que le compteur Tok contient suffisamment de 
5 jetons, c'est a dire que Tok est superieur ou egal a n, le processeur securise 
decremente le compteur de jetons Tok de la valeur n au cours d'une etape 
1004. 

Ensuite, le processeur securise signe un message contenant n, TO et 
IDM pour former un message note Sign(n,TO,IDM) avec un algorithme 

10 asymetrique et sa propre cle privee PriK conservee dans le registre 509. Puis, 
un message (1005,1006) contenant TO, Sign(n,TO,IDM) et la cle publique du 
processeur securise PubK 508 est transmis vers le marchand 902 a travers le 
decodeur 901. On note que le numero de transaction TO a pu etre memorise 
par le decodeur 901 et qu'ainsi le processeur securise 900 n'est pas oblige de 

15 transmettre TO au decodeur 901. La cle publique du processeur securise 
PubK est elle meme composee de deux entites : 

- une cle publique de signature notee PubK.key qui est utilisee pour 
I'algorithme de signature present sur le processeur securise ; et 

- la signature de la cle publique de signature PubK.key notee 
20 PubKSign qui a ete obtenue avec la cle privee de rintermediaire 

financier BPriK. 

Ainsi, le marchand verifie la validite de la transaction en verifiant d'une 
part la validite du certificat de cle publique en utilisant la cle publique de 
rintermediaire financier BPubK et d'autre part en verifiant la signature du 
25 triplet (n,TO,IDM) avec la cle publique de signature du processeur securise 
PubK.key. On note aussi, que rintermediaire financier peut ulterieurement 
effectuer les memes verifications. 

On note qu'une operation de validation du marchand peut etre inseree 
avant toute transaction. Elle peut par exemple consister en une emission d'un 
30 certificat du marchand vers un client. 

On note que dans une realisation telle que decrite en regard de la 
figure 2, le processeur securise 202 et le marchand 204 remplacent pour 
certaines operations le decodeur 901 dans le protocole decrit en regard de la 
figure 10. 

35 La figure 11 presente un protocole de rachat des jetons au marchand 

suite a une ou plusieurs transactions effectuees par un ou plusieurs clients. 
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Le rachat de jetons fait intervenir : 

- un marchand 902 tel que le marchand 104 ou 204 decrit en regard 
des figures 1 ou 2 ; et 

- un intermediate financier 1101 tel que I'intermediaire financier 100 
5 decrit en regard de la figure 1 . 

Si une transaction est reconnue comme correcte, I'intermediaire 
financier peut rembourser le marchand. On note que le remboursement des 
transactions relatives a un marchand donne (ou rachat de jetons au 
marchand) durant une periode peut se faire en une seule fois pour reduire les 

10 couts. L'intermediaire financier peut aussi reduire ses couts en ne verifiant 
completement que certaines transactions. En cas de detection d'une 
transaction non valide, I'intermediaire financier pourra verifier toutes les 
transactions effectuees par le marchand correspondant. Le procede de 
verification pourra etre optimise pour maximiser la rentabilite de I'intermediaire 

15 financier. 

L'operation de rachat des jetons est initiee par le marchand 902 qui, au 
cours d'une etape 1102, construit un message signe note MSign obtenu en 
signant avec sa propre cle privee MPriK conservee dans le registre 610, un 
quadruplet constitue de la valeur de la transaction n, du numero de 
20 transaction TO, de I'identificateur du marchand IDM et du message signe 
Sign(n,TO,IDM) emis par le processeur securise concerne par la transaction. 

Puis, le marchand 902 envoie a I'intermediaire financier 1101 un 
message 1103 de demande de remboursement de transaction comprenant la 
valeur de la transaction n, le numero de transaction TO, son identificateur 
25 /DM, le message signe Sign(n,TO,IDM), le message signe MSign et la cle 
publique du marchand MPubK 609. 

L'intermediaire financier 1101 peut alors verifier la transaction selon I'un 
des algorithmes decrits en regard des figures 13 ou 14 au cours d'une etape 
1104. 

30 En figure 12, qui presente une generation de numeros de transactions 

par un marchand 104 ou 204 tel qu'illustre en regard des figures 1 ou 2, on 
observe qu'apres une operation d'initialisation 1200 au cours de laquelle les 
registres de la memoire vive 605 et de la memoire non volatile 613 de type 
EEPROM sont initialises, au cours d'une operation d'attente 1201, le 

35 processeur 602 attend de recevoir puis regoit une nouvelle requete de 
transaction. 
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Puis, au cours d'une operation d'allocation 1202, le processeur 602 
alloue un numero de transaction TO puis memorise ce numero dans un 
registre 61 1 de dernier numero de transaction memorise LTO. 

Ensuite, au cours d'une operation d'attente 1203, le processeur 602 
5 attend de recevoir puis regoit une requete de transaction. 

Puis, au cours d'une operation d'allocation 1204, le processeur 602 
alloue un numero de transaction TO qui suit selon un ordre preetabli le dernier 
numero memorise LTO dans le registre 611. L'ordre est etabli notamment par 
le marchand, un intermediate financier ou un operateur technique. 
10 Selon le mode prefere de realisation, cet ordre preetabli sera l'ordre 

croissant des entiers naturels. TO sera alors obtenu par increment d'une unite 
de la valeur de LTO. 

Selon une variante, cet ordre preetabli sera l'ordre decroissant des 
entiers naturels ou un ordre quelconque qui par exemple depend du mode de 
15 representation de ces entiers. 

Selon une autre variante, le numero de transaction correspond a une 
heure et/ou une date. L'ordre preetabli est alors un ordre chronologique. 

Selon le mode prefere de realisation, le systeme est congu pour que 
TO n'atteigne jamais une valeur maximale definie par l'ordre preetabli dans un 
20 delai raisonnable. 

Selon une variante, le nombre de valeurs possibles que peut prendre 
TO est limite et lorsque TO atteint une valeur donnee de fin, la valeur suivante 
est une autre valeur donnee dite de debut. Ainsi, l'ordre preetabli a prendre 
en compte est un ordre en boucle. Dans le cas, par exemple ou on considere 
25 un compteur pouvant aller de 0 a 255, avec l'ordre naturel des entiers 
croissants, apres la valeur 255, on pourra attribuer la valeur 0 a TO. Pour 
comparer deux nombres, on considere alors une fenetre glissante de 
comparaison par exemple de taille 4. Ainsi, dans la fenetre glissante 
constitute des nombres 12, 13, 14 et 15, le nombre 14 est superieur aux 
30 nombres 12 et 13 et inferieur au nombre 15. Lorsqu'une fenetre glissante 
comprend la valeur de fin ou de debut, on veillera a considerer l'ordre 
d'attribution des numeros. Ainsi, dans la fenetre glissante constitute des 
nombres 254, 255, 0 et 1, le nombre 0 est superieur selon l'ordre en boucle 
preetabli aux nombres 254 et 255 et inferieur au nombre 1 . 
35 Les variantes d'ordre preetabli decrites ici ne sont pas Iimitatives et il 

existe de nombreuses possibilites pour l'ordre preetabli. D'une maniere 
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generate, cet ordre peut etre etabli notamment par le marchand, un 
intermediate financier ou un operateur technique. Si ce n'est pas le marchand 
104 ou 204 qui a etabli I'ordre de numerotation des transactions, les 
parametres de cet ordre preetabli sont transmis au marchand 104 ou 204 au 
5 prealable ou lors de ('operation deallocation 1202 par un moyen quelconque 
connu de I'homme du metier. 

Suite a I'operation d'allocation 1204, I'operation d'attente 1203 est 
reiteree. 

En figure 13, qui presente une validation de transactions par un 

10 intermediaire financier 100 tel qu'illustre en regard de la figure 8, on observe 
qu'apres une operation d'initialisation 1300 au cours de laquelle les registres 
de la memoire vive 805 et de la memoire non volatile 810 de type EEPROM 
sont initialises, au cours d'une operation d'attente 1301 le processeur 802 
attend de recevoir puis regoit une requete de remboursement de transaction 

15 emise par un marchand 104 ou 204. Cette requete comprend notamment la 
valeur de la transaction n, un numero de transaction TO, un identificateur du 
marchand /DM, un message signe Sign(n,TO,IDM) par un client, un message 
signe MSign par le marchand et la cle publique du marchand MPubK. 

Au cours d'un test 1302, le processeur 802 teste s'il s'agit d'une 

20 premiere requete valide issue du marchand M considere, identifie grace a 
I'identificateur IDM present dans la requete de remboursement. 

Dans la negative, le processeur effectue un test 1303 au cours duquel il 
verifie si le numero TO de la transaction consideree est superieur a un dernier 
numero de transaction valide effectuee par le marchand considere, ce dernier 

25 numero etant conserve dans un registre MLTO(M) 807. On suppose que le 
processeur effectue ce test en considerant le meme ordre preetabli que celui 
utilise par le marchand lors de I'allocation des numeros de transactions et qui 
a ete decrit en detail en regard de la figure 12. Si ce n'est pas I'intermediaire 
financier 100 qui a etabli Tordre de numerotation des transactions par le 

30 marchand M, les parametres de cet ordre preetabli sont transmis a 
I'intermediaire financier 100, au prealable ou lors du test 1303 par un moyen 
quelconque connu de I'homme du metier. 

Lorsque le resultat de I'un des tests 1302 ou 1303 est positif, le 
processeur 802 effectue un test de signature de la transaction incluant 

35 notamment un test de Sign et/ou de MSign tels que regu par I'intermediaire 
financier. 
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Lorsque la signature testee est valide, le processeur 802 effectue une 
mise a jour du registre de dernier numero de transaction enregistre pour le 
marchand MLTO(M) en memorisant dans ce registre la valeur du numero de 
transaction TO et Pintermediaire financier peut rembourser le marchand d'un 
5 montant n specifie par la requete. 

Lorsque le resultat de Tun des tests 1303 ou 1304 est negatif, le 
processeur 802 rejette la transaction au cours d'une operation 1306. 

A la suite de Tune des operations 1305 ou 1306, I'operation d'attente 
1301 est reiteree. 

10 La figure 14 presente un organigramme de validation de transactions 

par Pintermediaire financier selon une variante ou la verification des 
signatures est facultative. Les autres operations effectuees sont similaires aux 
operations de la figure 13 precedemment decrite qui portent les memes 
numeros de reference et ne seront pas decrits davantage. 

15 On observe que lorsque le resultat de Tun des tests 1302 ou 1303 est 

positif on effectue un test pour determiner si une verification de signature est 
requise. Au cours de ce test, on considere un indice de fiabilite du marchand. 
Si cet indice est inferieur a un seuil minimal de fiabilite, la signature est 
verifiee systematiquement. Si cet indice est superieur a ce seuil minimal de 

20 fiabilite, la signature ne sera pas systematiquement verifiee ; elle sera par 
exemple verifiee apres un tirage pseudo aleatoire dont la probabilite d'issue 
positive depend de Pindice de fiabilite du marchand ou selon une frequence 
qui est aussi dependante de Pindice de fiabilite du marchand. 

Lorsque le test 1407 requiert une verification de signature, le test 1304 

25 decrit precedemment est effectue. 

Lorsque le test 1304 est positif, le processeur 802 met a jour Pindice de 
fiabilite du marchand qui est augmente et un registre LTV de derniere 
transaction validee en y enregistrant le numero de transaction TO lors d'une 
operation de mise a jour 1408. 

30 Lorsque le test 1407 ne requiert pas de verification de signature ou 

apres I'operation de mise a jour 1408, le processeur 802 effectue I'operation 
1 305 precedemment decrite. 

Lorsque le resultat du test de signature 1304 est negatif, le processeur 
802 effectue une mise a jour de Pindice de fiabilite du marchand en la 

35 diminuant lors d'une operation 1409. 
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Puis, a Tissue d'un test 1303 negatif ou d'une operation 1409, la 
transaction est rejetee au cours cTune operation 1306. 

A la suite de cette operation de rejet 1306, au cours d'une operation 
1410, le processeur 802 effectue une operation de verification de toutes les 
5 transactions effectuees par le marchand considere M, 

- dont la signature n'a pas ete validee et 

- dont le numero TO est superieur au dernier numero LTV de 
transaction dont la signature a ete validee et/ou au dernier numero 
de transaction ayant regu une acceptation de paiement pour 

10 remboursement. (On note que Pacceptation de paiement n'est pas 

necessairement immediate apres la validation d'une transaction, 
mais se fait par exemple a une date precise chaque mois). 
Chaque transaction dont la signature n'est pas validee et qui avait ete 
validee dans un premier temps par un simple test de numero de transaction 
15 est finalement rejetee. Ensuite, une mise a jour de Pindice de fiabilite du 
marchand est effectuee. 

A la suite de Tune des operations 1305 ou 1410, I'operation d'attente 
1301 est reiteree. 

Bien entendu, I'invention n'est pas limitee aux exemples de realisation 

20 mentionnes ci-dessus. 

En particulier, I'homme du metier pourra apporter toute variante dans la 
definition des types de client, de marchand ou d'intermediaire financier 
lorsque le marchand applique un procede de gestion des transactions avec 
une allocation des numeros de transactions TO et/ou un intermediate 

25 financier valide une transaction numerotee ainsi telle que decrite dans le 
mode prefere de realisation. 

On note que Parchitecture du systeme ne se limite pas a une 
architecture triangulaire client, marchand, intermediaire financier mais s'etend 
a tout type d'architecture comprenant au moins un client, au moins un 

30 marchand et au moins un intermediaire financier relies entre eux. On peut 
ainsi considerer plusieurs clients pouvant effectuer des transactions avec 
plusieurs marchands, chacun des marchands etant relies a un ou plusieurs 
intermediaires financiers, chacun des clients pouvant effectuer des 
macropaiements avec un ou plusieurs intermediaires financiers qui ne sont 

35 pas necessairement les memes que ceux de chacun des marchands. 
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On notera que Pinvention ne se limite pas a une implantation purement 
materielle mais qu'elle peut aussi etre mise en oeuvre sous la forme d'une 
sequence destructions d'un programme informatique ou toute forme mixant 
une partie materielle et une partie logicielle. Dans le cas ou Tinvention est 
5 implantee partiellement ou totalement sous forme logicielle, la sequence 
constructions correspondante pourra etre stockee dans un moyen de 
stockage amovible (tel que par exemple une disquette, un CD-ROM ou un 
DVD-ROM) ou non, ce moyen de stockage etant lisible partiellement ou 
totalement par un ordinateur ou un microprocesseur. 



WO 02/05226 



27 



PCT/FR01/02202 



REVENDICATIONS 

1. Procede de gestion de transaction de micropaiement, entre un marchand 
(104) et au moins un client (101, 201) caracterise en ce que, a chaque 
5 nouvelle transaction, 

ledit marchand (104) alloue (1204) un nouveau numero de transaction 
(TO) qui suit selon un ordre preetabli de numerotation un dernier 
numero memorise (LTO) et 
- Iedit marchand (104) met a jour (1204) un registre de dernier numero 
10 memorise (LTO) en enregistrant ledit nouveau numero de transaction 

(TO), 

chaque dit numero de transaction (TO) etant susceptible d'etre verifie par un 
intermediate financier (100). 

15 2. Procede de gestion de transaction de micropaiement selon la revendication 
1, caracterise en ce qu'au moins un client (101, 201) parmi lesdits clients est 
un terminal (103) multimedia numerique et/ou analogique. 

3. Procede de gestion de transaction de micropaiement selon la revendication 
20 2, caracterise en ce que ledit terminal (103) multimedia comprend au moins 

un processeur securise fixe (102, 406) ou amovible (102, 500) necessaire a la 
mise en oeuvre desdites transactions de micropaiement. 

4. Procede de gestion de transaction de micropaiement selon Tune 
25 quelconque des revendications 1 a 3, caracterise en ce que ledit marchand 

(104, 204) est equipe d'un lecteur (711) de processeur securise amovible. 

5. Procede de gestion de transaction de micropaiement selon la revendication 
4, caracterise en ce qu'au moins un client (101, 201) parmi lesdits clients est 

30 un processeur securise amovible (102,500) lisible par ledit lecteur (711) de 
processeur securise amovible dudit marchand (104, 204). 

6. Procede de gestion de transaction de micropaiement entre un client (101, 
201) et un marchand (104) par un intermediate financier (100), caracterise en 

35 ce que 
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pour un premier ensemble d'au moins une transaction realisee par ledit 
marchand (104) et possedant un numero de transaction (TO) alloue par ledit 
marchand (104), ledit intermediate financier (100) effectue pour chaque 
transaction dudit premier ensemble 
5 - au cours d'une premiere etape, une operation de verification (1303) de 
ladite transaction consistant a determiner si ledit numero de transaction 
(TO) suit selon un ordre preetabli un dernier numero de transaction 
enregistre (MLTO(M)) puis 

- au cours d'une deuxieme etape, 

10 - lorsque le resultat de ladite operation de verification est negatif, une 
operation (1306) de rejet de ladite transaction ; 
- et lorsque le resultat de ladite operation de verification est positif, une 
operation d'enregistrement (1305) dudit numero de transaction (TO) en 
tant que dernier numero de transaction {MLTO(M)) pour ledit 

15 marchand. 

7. Procede de gestion de transaction de micropaiement selon la revendication 

6, caracterise en ce que I'operation de verification de ladite transaction 
comprend en outre une operation de verification (1304) de signature de ladite 

20 transaction. 

8. Procede de gestion de transaction de micropaiement selon la revendication 

7, caracterise en ce que I'operation de verification de ladite transaction est 
effectuee selon (1407) un indice de fiabilite dudit marchand. 

25 

9. Procede de gestion de transaction de micropaiement selon la revendication 

8, caracterise en ce que la verification de signature (1304) de la dite 
transaction est effectuee 

- systematiquement si ledit indice de fiabilite dudit marchand est inferieur a 
30 un seuil ; 

- non systematiquement si ledit indice de fiabilite dudit marchand est 
superieur au dit seuil. 

10. Procede de gestion de transaction de micropaiement selon la 
35 revendication 9, caracterise en ce que lorsque le resultat de I'operation de 

verification de signature (1304) de ladite transaction est negatif, le procede 
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comprend en outre une operation (1410) de verification des signatures d'un 
deuxieme ensemble de transactions. 

11- Procede de gestion de transaction de micropaiement selon la 
5 revendication 10, caracterise en ce que ledit deuxieme ensemble de 
transactions comprend toutes les transactions presentees par ledit marchand 
audit intermediaire financier depuis une transaction de reference et dont la 
signature n'a pas deja ete verifiee. 

10 12. Procede de gestion de transaction de micropaiement selon la 
revendication 11, caracterise en ce que ladite transaction de reference est : 

- la derniere transaction ayant regu une acceptation de paiement ; et/ou 

- la derniere transaction (LTV) precedent ladite transaction de 
micropaiement dont la signature a ete verifiee. 

15 

13. Procede de gestion de transaction de micropaiement selon Tune 
quelconque des revendications 8 a 12, caracterise en ce que ledit 
intermediaire financier est susceptible de mettre a jour la fiabilite dudit 
marchand en fonction du resultat d'au moins une desdites verifications de 

20 signature (1304). 

14. Procede de gestion de transaction de micropaiement selon Tune 
quelconque des revendications 1 a 13, caracterise en ce que ledit ordre 
preetabli a ete etabli par ledit marchand (104) ou ledit intermediaire financier 

25 (100) ou un operateur technique. 

15. Procede de gestion de transaction de micropaiement selon Tune 
quelconque des revendications 1 a 14, caracterise en ce que ledit ordre 
preetabli est 

30 - I'ordre naturel des entiers croissants ; et/ou 

- un ordre chronologique de type heure et/ou date. 

16. Procede de gestion de transaction de micropaiement selon Tune 
quelconque des revendications 1 a 15, caracterise en ce que ledit ordre 

35 preetabli est un ordre en boucle. 
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17. Systeme caracterise en ce qu'il comprend des moyens adaptes a la mise 
en oeuvre d'un procede de gestion de transaction de micropaiement selon 
Tune quelconque des revendications 1 a 16. 

5 18. Dispositif de gestion de transaction de micropaiement, entre ledit dispositif 
et au moins un client, caracterise en ce qu'il comprend pour chaque nouvelle 
transaction, 

- un moyen d'allocation de nouveau numero de transaction (TO) qui suit 
selon un ordre preetabli de numerotation un dernier numero memorise 

10 (LTO) ; et 

- un moyen de mise a jour dudit registre de dernier numero memorise (LTO) 
ledit moyen de mise a jour enregistrant ledit nouveau numero de 
transaction ; 

chaque dit numero de transaction (TO) etant susceptible d'etre verifie par un 
15 intermediate financier (1 00). 

19. Dispositif de gestion de transaction de micropaiement entre un client (101, 
201) et un marchand (104), caracterise en ce que 

pour un premier ensemble de transactions realisees par ledit marchand (104) 
20 et possedant un numero de transaction (TO) alloue par ledit marchand (104), 
ledit dispositif comprend pour chaque transaction dudit premier ensemble 

- un moyen de verification de ladite transaction adapte a determiner si ledit 
numero de transaction (TO) suit selon un ordre preetabli un dernier 
numero de transaction enregistre (MLTO(M)) ; 

25 - lorsque le resultat de ladite operation de verification est negatif, un moyen 
de rejet de ladite transaction ; 

- et lorsque le resultat de ladite operation de verification est positif, un 
moyen d'enregistrement dudit numero de transaction (TO) en tant que 
dernier numero de transaction (MLTO(M)) pour ledit marchand (104). 

30 

20. Terminal numerique multimedia, caracterise en ce qu'il comprend au 
moins un processeur securise fixe (102, 406) ou amovible (102, 500) et en ce 
que ledit processeur securise (102, 406, 500) est adapte a effectuer des 
transactions de micropaiements en tant que client (101,201). 

35 
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21. Terminal numerique multimedia selon la revendication 20 caracterise en 
ce qu'il est un decodeur numerique multimedia (103). 
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